用户故事与敏捷方法 [User Stories Applied:For Agile Software Development] mobi epub pdf txt 电子书 下载 2024

发表于2024-07-10

　　敏捷大师Mike Cohn的软件需求方法圣经，小型团队(项目)不可或缺的敏捷开发宝典，五星级长销图书，敏捷社区重点推荐，结合精髓和实例，充分演绎用户故事的智慧。

　　在敏捷社区的详尽评审和热切期盼下， 《用户故事与敏捷方法》不负众望.为软件行业提供了一种节省时间和消除重复工作的需求管理方法.对开发更优秀的软件起着积极、高效的推动作用。

　　构建满足用户需求的软件.推荐的方法是从“用户故事”开始，即简明扼要、清楚明确地描述对实际用户有价值的功能。在《用户故事与敏捷方法》中.敏捷大师Mike cohn提供详尽的蓝图来指导我们如何编写用户故事.如何把它们应用于软件开发生命周期中。

　　《用户故事与敏捷方法》介绍了如何编写理想的用户故事，造成用户故事不理想的原因有哪些，如何在无法与用户交流的情况下有效地搜集用户故事.如何对已经写好的用户故事进行整理、排列优先级及在此基础上进行计划、管理和测试。

　　·专注于“用户故事”这一灵活、敏捷和实用的需求方法。

　　·强调如何用更短的时间开发更符合用户需求的软件应用。

　　·揭示如何在不能直接与用户交流的情况下搜集用户故事。

　　·诠释用户故事的优势，用户故事与用例、使用场景和传统需求方法的不同。

　　·精辟阐述如何围绕着用户故事进行全面的规划、进度、估算和测试。

　　·极限编程(Extreme Programming)，scrum或其他任何敏捷方法的伴侣。

　　采用XP和scrum等敏捷开发方法或其他软件开发方法的开发人员、测试人员，分析师和管理人员．可以从《用户故事与敏捷方法》获得有价值的信息，以更少的人员在更少的时间内开发出更符合用户需求的软件应用

　　《用户故事与敏捷方法》详细介绍了用户故事与敏捷开发方法的结合，诠释了用户故事的重要价值，用户故事的实践过程，良好用户故事编写准则，如何搜集和整理用户故事，如何排列用户故事的优先级，进而澄清真正适合用户需求的、有价值的功能需求。　　《用户故事与敏捷方法》对于软件开发人员、测试人员、需求分析师和管理者，具有实际的指导意义和重要的参考价值。

　　科恩（Mike Cohn），是敏捷联盟的发起成员之一，并担任其文章项目的总监。他1984年开始编程，1988年开始管理软件项目，客户包括富达投资、维亚康姆、宝洁、NBC和花旗银行。Mike写本书时是Fast401k的软件工程副总裁。这家行业领先公司提供基于互联网的401（k）档案保存和管理解决方案。Fast401k向金融服务行业客户提供自主品牌的e401k软件产品，作为外包服务供应商，利用专有技术实现规模经济效应。在本书之前，Mike著有或合写了4本编程方面的书籍。（译者注：Mike也是《敏捷估计及估算》及Succeedingwith Agile两本重要敏捷著作的作者，并与其他两位敏捷泰斗Ken Schwaber和EstherDerbv一起创办了Scrum联盟。）

第I部分 起 步第1章 概览 3什么是用户故事？ 4细节在哪里？ 5“必须多长时间完成？” 6客户团队 7使用故事的过程是怎么样的？ 7规划发布和迭代 9什么是验收测试？ 11为什么要变？ 12小结 13问题 14

第2章 编写故事 15独立的 15可讨论的 16对用户或客户有价值的 18可估计的 19小的 20分割故事 21合并故事 23可测试的 23小结 24开发人员职责 25客户团队职责 25问题 25

第3章 用户角色建模 27用户角色 27角色建模的步骤 28通过头脑风暴，列出初始的用户角色集合 29整理最初的角色集合 30整合角色 31提炼角色 32两个额外的技术 33虚构人物 33极端人物 34如果有现场用户该如何？ 35小结 35开发人员职责 35客户职责 35问题 36

第4章 搜集故事 37引出和捕捉是不合用的 37够用就行，不是吗？ 38方法 38用户访谈 39问卷调查 41观察 41故事编写工作坊 42小结 45开发人员职责 45客户职责 45问题 46

第5章 与用户代理合作 47用户的经理 47开发经理 48销售人员 49领域专家 49市场营销团队 50以前的用户 50客户 51培训师和技术支持 52业务分析师或系统分析师 52与用户代理合作时，做些什么？ 52能接触到用户但访问受限时 52实在不能接触到用户时 53可以自己来吗？ 54设立客户团队 54小结 55开发人员职责 55客户团队职责 56问题 56

第6章 用户故事验收测试 57在写代码之前写测试 58客户定义测试 59测试是过程的一部分 59多少测试才算多？ 59集成测试框架 60测试类型 61小结 62开发人员职责 62客户职责 62问题 62

第7章 优秀用户故事准则 63从目标故事开始 63切蛋糕 63编写封闭的故事 64卡片约束 65根据实现时间来确定故事规模 65不要过早涉及用户界面 66有些需求并不是故事 67在故事里包括用户角色 67只为一个用户编写 68以主动语态编写 68由客户编写 68向故事卡编号说“不” 68不要忘记意图 69小结 69问题 70

第II部分 估算和计划第8章 估算用户故事 73故事点 73以团队估算 74估算 74三角测量 75使用故事点 76如果用结对编程呢？ 77一些提醒 78小结 79开发人员职责 79客户职责 79问题 79

第9章 发布计划 81我们想在什么时候发布 81希望在发布中包含哪些功能？ 82排列故事优先级 82混合优先级 84高风险故事 84根据架构需要安排优先级 85选择迭代长度 86从故事点到预计工期 86初始速率 87猜测速率 87创建发布计划 88小结 88开发人员职责 89客户职责 89问题 89

第10章 迭代计划 91迭代计划概览 91讨论故事 91分解任务 92准则 93承担职责 94估算并确认 94小结 95开发人员职责 96客户职责 96问题 96

第11章 测量并监控速率 97测量速率 97计划速率和实际速率 98迭代燃尽图 100迭代中的燃尽图 102小结 104开发人员职责 105客户职责 105问题 105

第III部分 经常讨论的话题第12章 故事不是什么 109用户故事不是IEEE 830 109用户故事不是用例 112用户故事不是场景 115小结 117问题 118

第13章 用户故事的优势 119口头沟通 119用户故事容易理解 121用户故事的大小适合做计划 122用户故事适合于迭代开发 123用户故事鼓励延迟细节 124用户故事支持随机应变的开发 124用户故事鼓励参与性设计 125用户故事传播隐性知识 126用户故事的不足 126小结 127开发人员职责 127客户职责 128问题 128

第14章 用户故事不良症兆一览 129故事太小 129故事互相依赖 129镀金 130细节太多 131过早考虑用户界面细节 131想得太远 132故事划分太过频繁 132客户很难为故事安排优先级 132客户不愿意写用户故事，也不愿意为故事安排优先级 133小结 134开发人员职责 134客户职责 134问题 134

第15章 Scrum与用户故事 135Scrum是迭代和递增的 135Scrum基础 136Scrum团队 137产品Backlog 137Sprint计划会议 138Sprint评审会议 140每日Scrum简会 140在Scrum中使用用户故事 142Scrum和产品Backlog 142在Sprint计划会议中使用用户故事 142在Sprint评审会议中使用用户故事 143在每日Scrum简会中使用用户故事 143一个案例 143小结 144问题 145

第16章 其他话题 147处理非功能性需求 147纸质还是软件? 148用户故事和用户界面 150保留故事 152缺陷的用户故事 154小结 154开发人员职责 155客户职责 155问题 155

第IV部分 一个完整的实例第17章 用户角色 159项目 159定义客户 159定义一些角色雏形 160整合与提炼 161角色建模 162添加虚构人物 164

第18章 一些用户故事 165Teresa的故事 165Ron船长的故事 168“初级航海者”的故事 168“不出海的礼物购买者”的故事 169“报表查阅者”的故事 169“管理员”的一些故事 170收尾 171

第19章 估算故事 173第一个故事 174高级搜索 176评分和评论 177账户 177完成估算 178所有估算 179

第20章 发布计划 181估算速率 181给故事安排优先级 181最终的发布计划 182第21章 验收测试 185搜索测试 185购物车测试 186购买书 187用户账户 187管理 188测试限制条件 189最后一个故事 190

第V部分 附 录附录A 极限编程概览 193附录B 参考答案 203

　　我们需要一种协同工作的方法，让双方都不占绝对主导地位，共同面对感情用事和办公室政治化的资源分配问题。若资源分配问题完全落在一方，项目必定会失败。如果只让开发人员来承担这些问题（他们通常会被告知“我不关心你们怎么做，但请你们在6月份之前完成”），他们可能会牺牲质量来换取额外的特性，也可能只部分实现一个特性，或者自行做出一些本该在有客户和用户参与情况下才能做出的决定。如果只是客户和用户承担资源分配的责任，那么我们通常会在项目开始时看到一系列漫长的讨论，项目中的特性逐渐减少。之后，在最终发布软件时，只剩下很少的功能，甚至少于被减掉的功能。

　　至此我们已经了解到，我们不能完美地预测软件开发项目。当用户看到软件的早期版本时，他们会想出新的点子，从而改变他们的观点。由于软件的这种不可控性，大部分开发人员都会遇到众所周知的艰难时刻，估计需要多长时间才能完事儿。因为这些因素及其他一些因素，导致我们无法勾勒出一幅完美的PERT图①来展示项目中所有必须完成的事情。

　　……

　　数年前，Mike Cohn写了这本User Stories Applied： For Agile Software Development，而我从2007年才真正开始接触敏捷，没想到在2009年我竟有机会能够参与翻译这本有关用户故事的经典著作，我感到十分的荣幸。　　敏捷开发近些年在国内软件开发公司中十分流行，因为它为软件开发指引了一个方向。而用户故事是敏捷实践中一个十分重要的环节。它能帮助我们高效地收集客户真正的需求。软件开发都起始于需求收集与分析。如果一开始需求都弄错了，软件的成功也就无从谈起。同时，用户故事带来了一个十分重要的作用，即高效沟通，不论是开发团队与客户的沟通，还是团队内部成员之间的沟通。沟通使客户和团队成员都朝同一个方向前进，这意味着更少的错误，更少的浪费、风险和成本。用户故事还是敏捷计划与估算的重要基础。　　我十分有幸能在Irdeto BSS进行敏捷开发。在这里，我们使用Scrum，结合XP进行开发。用户故事自然是不可或缺的。在这里，每个团队都有一个白板，上面贴有一些卡片。它们是这个Sprint团队计划完成的用户故事以及这些故事划分的任务。这些用户故事卡片概要描述了需求，形如“作为(角色)，我想要(功能)，以此(商业价值)”，有时上面还附着另一张卡片写着验收条件。在做计划和开发的时候，团队可以拿着这个用户故事讨论故事细节，故事如何才算完成，等等，正如Ron Jeffries所描述的3C：Card(卡片)，Conversation(交谈)和Confirmation(确认)。　　用户故事从始至终贯穿于整个开发流程。首先产品负责人根据收集来的需求编写用户故事，放入产品Backlog中。在Sprint计划会议中，团队成员讨论其中的一些用户故事，细化故事细节，确定验收标准，使用Planning Poker(计划扑克)估算故事点。然后，将故事分成一些小的任务，并估算工作时间。最后，将故事放入Sprint Backlog中，并按优先级排序。Sprint开始时，故事卡片和任务卡片都放在白板的To Do栏，团队成员按故事的优先级挑选任务，将任务卡片挪到Doing栏。任务完成后，将任务卡片挪到Done栏。团队尽可能地先完成优先级高的故事。在故事开发的初始阶段，测试人员和产品负责人一起确认测试用例。故事的任务都完成后，产品负责人验收并确认故事已完成，将故事卡片挪到Done栏中。如此完成整个Sprint的所有故事。Sprint结束时，团队还要将完成的故事演示给利益相关人、其他产品负责人和团队等。这样，每个Sprint团队都会通过完成一系列的用户故事来向客户输出商业价值。　　这次翻译我们一共四个人参与，我和石永超主要负责翻译，滕振宇和李国彪主要负责审核。前期的第一个月，我们几乎没有什么太大的进展。我们讨论过后，发现这次翻译其实是一个具有固定交付时间、固定范围(21章和两个附录)且依赖虚拟兼职开发团队的项目，包含开发(翻译)和测试(审核)等工作，何不用敏捷的方式来开展？于是，第二个月开始，我们使用敏捷的思想来指导翻译工作。我们首先把每一章当作一个用户故事，每个故事估算一个故事点(这个是我们做的不足的地方，一个故事点显然不能准确反映各章的不同篇幅)。我们以一个星期为一个迭代，用一份Excel文档作电子白板。每个周末固定时间用Skype开一次网上语音会议。如同Scrum的每日例会一样，大家回答三个问题：这个星期我做了什么，下个星期准备做什么，有什么困难。然后讨论大家遇到的一些翻译难点，统一一些术语的翻译。大家在完成每个星期的翻译工作的同时，必须及时简单地更新Excel中故事的状态。这样一来，每个人都能及时知道每一章的进度，哪一章可以审核，哪一章没有人翻译，可以任领。同时，Excel中还有燃尽图，告诉我们离目标还有多远，是否需要调整。如此，这份Excel文档就成为我们的另一个沟通工具。另外，我们还有十分重要的工具，如同我们的软件项目一样，对于项目中的所有文件(包括电子白板和术语表)，我们使用版本管理工具Subversion和持续集成工具CruiseControl。我们每次签入，持续集成工具都会立即发一封邮件通知大家有新的改动，邮件包含有签入的描述，这样可以提醒大家某一章翻译完了，应该审核，等等 。这样，从第二个月开始，我们的翻译工作就始终保持稳定的进度，团队通过更多更频繁的回馈不断学习成长，持续改善译稿和翻译过程，最终按时交付了翻译稿。　　这次翻译成为我们软件开发之外的一次敏捷实践，获益良多。同样，我们也希望能够让更多的人了解敏捷，让更多从事软件开发的人和其他行业的人从中获益。翻译这本书也希望能为传播敏捷思想与方法尽一份力。让更多的人了解用户故事，使用用户故事，带来更多成功的项目。　　在此感谢一起翻译的伙伴们：李国彪、滕振宇和石永超。感谢你们让我能够获得参与翻译此书的机会，我从中学习了很多很多，不仅仅是对用户故事更深入的了解，还有在这次翻译过程中对敏捷更全面、深刻的理解。

用户故事与敏捷方法 [User Stories Applied:For Agile Software Development] 下载 mobi pdf epub txt 电子书 格式 2024

一次性买了很多好书，慢慢看。

敏捷开发，这本书很经典，很好，很不错

好棒的经典书目，了解到了什么是oop

碰上京东活动，书质量不错，可学习敏捷开发与管理

好东西大家齐分享！买不了吃亏上当

好评，京东老客户！

很好(?▽?)

产品不错，物流快捷，给小哥点赞

学无止境 买来看看 希望get到更多的点

用户故事与敏捷方法 [User Stories Applied:For Agile Software Development] mobi epub pdf txt 电子书 格式下载 2024